PD-6046 PD-6045 PD-6045 PD-6046 PD-6044 PD-6042 PD-6043 PD-5850 add 2FA recovery phone number - #7655

RedisClient hardcoded .ssl(true). A plaintext Redis does not reject a TLS
handshake, it simply never answers, so every connect blocked until the
socket read timed out: 20 s for the two 10 s-timeout clients and 40 s for
the 20 s one. Four clients are built per startup because web.xml builds the
Spring context twice, which is 120 s of a 148 s deploy.

Add a ssl constructor argument defaulting to true, wired through all four
bean definitions as ${...ssl.enabled:true}. Production keeps TLS with no
configuration change. This mirrors SessionCacheConfig, which already reads
...cache.session.redis.ssl.enabled with the same shape and the same default.

Turning TLS off then exposed a second defect: a blank password was still
passed to the Jedis config, so the client sent AUTH "" and an unauthenticated
Redis answered

  ERR AUTH <password> called without any password configured for the default user

which meant the pool never came up and the cache stayed silently disabled --
set() returning false and get() returning null for every caller. Treat a
blank or null password as "no authentication". A configured password is
unaffected.

Measured on an isolated Tomcat against the real WAR, with the context still
built twice and the original timeouts: startup 148.5 s -> 44.9 s, and three
Redis clients now connect successfully where none did before.

(cherry picked from commit 57c6a37)